http://blog.csdn.net/chszs/article/details/46592777

http://nikipore.github.io/stompest/

https://stomp.github.io/stomp-specification-1.1.html#Heart-beating

https://nikipore.github.io/stompest/protocol.html

the sender MUST send new data over the network connection at least every  milliseconds   配了heartbeat，你就必须主动发数据，否则会被断开

An id header MUST be included in the frame to uniquely identify the subscription within the STOMP connection session. Since a single connection can have multiple open subscriptions with a server, the id header allows the client and server to relate subsequent ACK, NACK or UNSUBSCRIBEframes to the original subscription.

StompConfig(uri, amq_config['USER'], amq_config['PASSWORD'], version=StompSpec.VERSION_1_2)

1.2版本的subscribe消息需要id头

STOMP即Simple (or Streaming) Text Orientated Messaging Protocol，简单(流)文本定向消息协议，它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理（Broker）进行交互。STOMP协议由于设计简单，易于开发客户端，因此在多种语言和多种平台上得到广泛地应用。

STOMP协议的前身是TTMP协议（一个简单的基于文本的协议），专为消息中间件设计。

STOMP是一个非常简单和容易实现的协议，其设计灵感源自于HTTP的简单性。尽管STOMP协议在服务器端的实现可能有一定的难度，但客户端的实现却很容易。例如，可以使用Telnet登录到任何的STOMP代理，并与STOMP代理进行交互。

STOMP协议与2012年10月22日发布了最新的STOMP 1.2规范。要查看STOMP 1.2规范，见： https://stomp.github.io/stomp-specification-1.2.html

业界已经有很多优秀的STOMP的服务器/客户端的开源实现，下面就介绍一下这方面的情况。

这里只列了部分。

这里只列了部分。

STOMP协议与HTTP协议很相似，它基于TCP协议，使用了以下命令：

CONNECTSENDSUBSCRIBEUNSUBSCRIBEBEGINCOMMITABORTACKNACKDISCONNECT

STOMP的客户端和服务器之间的通信是通过“帧”（Frame）实现的，每个帧由多“行”（Line）组成。第一行包含了命令，然后紧跟键值对形式的Header内容。第二行必须是空行。第三行开始就是Body内容，末尾都以空字符结尾。STOMP的客户端和服务器之间的通信是通过MESSAGE帧、RECEIPT帧或ERROR帧实现的，它们的格式相似。

http://diaocow.iteye.com/blog/1725186

==========

Stomp是一个简单的消息文本协议,它的设计核心理念就是简单与可用性，官方文档：http://stomp.github.com/stomp-specification-1.1.html 

现在我们就来实践一下Stomp协议，你需要的是： 

1.一个支持stomp消息协议的messaging server(譬如activemq，rabbitmq）； 2.一个终端（譬如linux shell); 3.一些基本命令与操作（譬如nc，telnet) 

1.建立连接 当我们（Client端）向服务器发送一个CONNECT Frame，就向服务器发起了一个连接请求，此时服务器端返回一个CONNECTED Frame表示建立连接成功，其中头字段version表示采用的stomp协议版本（这里默认是1.0） 

 ps: ^@符号 ctrl+@键(用来提交请求），删除之前输入的数据 ctrl+n+backspace键 

当然Client端也可指定所支持的协议版本（accept-version字段，多个版本按递增顺序排列，并用逗号分隔）； 

服务器此时返回的CONNECTED Frame中会列出它所支持的协议版本号中最高的那个（如上图的version：1.1） 

如果服务器端不支持客户端所列举的协议版本（比如这里的2.1），那么服务器会返回一个ERROR Frame并且列举出服务器自己所支持的协议版本（如下图的version:1.0,1.1） 

2.消息传递 客户端一旦与服务器端建立连接，那么就可发送下列Frame进行消息传递 

SEND Frame 用来将客户端消息发送到目的地（destination）,因此它必须指定一个destination头字段，另外在所有头字段之后，新起一个空行，之后就是需要发送的消息（譬如这里的 hello stomp!) 

此时"hello stomp!" 这条消息就被发送到了队列 my_queue中去 

现在我们再起一个客户端clinet_a，来接受这个队列（myqueue）中的消息 

SUBSCRIBE Frame 表示客户端希望订阅某一个目的地（destination）的消息（这里是/queue/my_queue），其中头字段id表示在一个会话连接里，唯一标示一个订阅者（subscription），头字段destination标示该订阅者（subscription）需要订阅的目的地（这里是一个队列，/queue/my_queue) 

紧接着，我们就接受到服务器端发送来的消息（MESSAGE Frame），其中message_id:唯一标示了这条消息（后面我们会使用这个消息id进行ack,uack操作），content-length:标示消息体的长度，在所有这些头后面，新起一个空行就是消息内容（如这里的hello stomp!） 

如此时我们希望订阅另一个destination，该如何办呢？，是不是再发送一个SUBSCRIBE Frame就好了？ 

结果发现服务器端返回了ERROR Frame 告诉我们SUBSCRIBE失败，原来同一个subscription id只能订阅一个destination，要想订阅令一个destination，必须先发送UNSUBSCRIBE Frame,然后再SUBSCRIBE 到新的目的地 

UNSCUBSCRIBE Frame中的id标示需要取消订阅的subscription，然后我们在订阅到新的destination（这里是/queue/other_queue),可以发现订阅成功，服务器没有再发送ERROR Frame 

至此，我们就模拟出了一个PTP（point-to-point）消息模型，下面我们也模拟下另外一个pub/sub消息模型： 

准备工作，新起两个连接订阅到/topic/my_topic上，如下图: clinet_a  

client b  

Send端发送广播消息：  

我们去检查下两个消息接收客户端，果然发现收到了这条广播消息^_^ client a  

client b  

默认情况下，只要服务器端发送消息，就认为客户端接收成功（即ack模式为auto），若我们需要更严格的消息保证，则必须采用client模式，即由客户端确认消息的接受 

服务器发送了一个消息到/queue/ackqueue 

此时我们的客户端client_a确实接受到了该消息 

虽然该消息已经发送到客户端，但是由于该消息没有确认（ack），则该消息还保存在队列/queue/ackqueue中（直到客户端确认才删除），我们可以通过rabbitmq提供的命令来查看（sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged）： 

若客户端在确认消息前与客户端断开连接，那么服务器可能(根据不同server的设计而不同)会选择将该消息发送给另一个subscription（这里是client_b） 

可以看出rabbit是选择将它发送给另一个subscription， 我们在使用命令查ack_queue队列中是否还有未确认的消息 

结果发现没有了 ^_^ 

若是客户端希望确认一个消息，该如何做呢？，只要发送一个ACK Frame即可! 在ACK Frame中，subscription标示是谁确认消息，message-id标示是确认哪条消息（即MESSAGE Frame中携带的message-id） 

另外我在rabbitmq的测试结果发现，ack具有累积效应(因为这里SUBSCRIBE帧的ack头被设置成了‘client’)，譬如接收了10条消息，如果你ack了第8条消息，那么1-7条消息都会被ack，只有9-10两条消息还保持未ack状态 

除了有ACK Frame，还有NACK Frame，它表示客户端未成功接收某条消息，这时候服务器可以选择重发或者丢弃（对于rabbitmq，我的测试结果是选择重发） 

3.断开连接 说完了连接的建立，消息的发送与接收，现在我们来看看客户端如何与服务器断开连接的，更重要的是如何安全的断开连接 

通过发送DISCONNNECT Frame表示向服务器发送一个断开连接请求，其中receipt表示服务器收到请求后请告知客户端，并返回一个相同的receipt-id 

至此关于Stmop绝大部分概念，我们已经实践完毕，如需更详细的还请翻阅官方文档 ^_^ 

================

http://www.cnblogs.com/davidwang456/p/4449428.html

http://nikipore.github.io/stompest/sync.html?highlight=stompest%20sync#module-stompest.sync.client

STOMP是基于帧的协议，它假定底层为一个2-way的可靠流的网络协议（如TCP）。客户端和服务器通信使用STOMP帧流通讯。帧的结构看起来像：

帧以command字符串开始,以EOL结束，其中包括可选回车符（13字节），紧接着是换行符（10字节）。command下面是0个或多个:格式的header条目, 每个条目由EOL结束。一个空白行（即额外EOL）表示header结束和body开始。body连接着NULL字节。本文档中的例子将使用^@,在ASCII中用control-@表示，代表NULL字节。NULL字节可以选择跟多个EOLs。欲了解更多关于STOMP帧的详细信息，请参阅Augmented BNF节本文件。

本文档中引用的所有command 和header 名字都是大小写敏感的.

只有SEND, MESSAGE, 和ERROR帧有body。所有其他的帧不能有body。

任何客户端帧(除了CONNECT帧)都可以为receipt header指定任何值。这会让服务端应答带有RECEIPT的客户端帧的处理过程。

如果client或者server收到重复的header条目，只有第一个会被用作header条目的值。其他的值仅仅用来维持状态改变，或者被丢弃。

例如，如果client收到:

foo header的值为World.

为了客户端滥用服务端的内存分配，服务端可以设置可分配的内存大小:

如果超出了这些限制，server应该向client发送一个error frame,然后关闭连接.

STOMP servers必须支持client快速地连接server和断开连接。 这意味着server在连接重置前只允许被关闭的连接短时间地延迟.

结果就是，在socket重置前client可能不会收到server发来的最后一个frame(比如ERROR或者RECEIPTframe去应答DISCONNECTframe)

client可以发送下列列表以外的frame，但是STOMP1.2 server会响应ERROR frame,然后关闭连接。

SUBSCRIBE frame用于注册给定的目的地. 和SENDframe一样，SUBSCRIBEframe需要包含destination header表明client想要订阅目的地。 被订阅的目的地收到的任何消息将通过MESSAGE frame发送给client。 ack header控制着确认模式。

例子:

如果server不能成功创建此次订阅，那么server将返回ERROR frame然后关闭连接。

STOMP服务器可能支持额外的服务器特定的头文件，来自定义有关订阅传递语义.

一个单连接可以对应多个开放的servers订阅,所以必须包含id header去唯一标示这个订阅. 这个id frame可以把此次订阅与接下来的MESSAGE frame和UNSUBSCRIBE frame联系起来。

在相同的连接中，不同的订阅必须拥有不同订阅id。

ack header可用的值有auto, client, client-individual, 默认为auto.

　　　　client发送的ACK frame被当作是积累的确认。这就意味这种确认方式会去操作ACK frame指定的消息和订阅的所有消息. 

　　　　譬如接收了10条消息，如果你ack了第8条消息，那么1-7条消息都会被ack，只有9-10两条消息还保持未ack状态。

　　　　由于client不能处理某些消息，所以client应该发送NACK frame去告诉server它不能消费这些消息。

用来确认订阅的消息被消费了.

server偶尔也会发送frame给客户端(除了连接最初的CONNECTED frame).

这些frames为: * MESSAGE * RECEIPT * ERROR

server成功处理带有receipt头的client frame后， 将发送RECEIPT frame到client.  RECEIPT frame必须包含receipt-id header,它的值为client frame中receipt header的值。

RECEIPT frame是作为server处理的client frame后的应答. 既然STOMP是基于流的，那么receipt也是对server已经收到所有的frames的累积确认。但是，以前的frames可能并没有被完全处理。如果clients断开连接，以前接收到的frames应该继续被server处理。

=====

If you use ActiveMQ to run these examples, make sure you enable the STOMP connector, (see here for details):

For debugging purposes, it is highly recommended to turn on the logger on level DEBUG: